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Trauma  Patient  Followup  Registry 
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Overvi ew 


*“The  goal  of  this  project  has  been  to  explore  and  document  the 
information  management  capabilities  needed  to  develope  a 
transportabl e  spartan  but  automated  patient  care  record  for  trauma 
patients  which  would  be  a  model  for  a  comparable  system  to  be  used 
in  the  echelons  of  care  employed  by  military  operational  medicine 
and  for  which  the  Fleet  Marine  Force  is  the  model.  While  this  goal 
has  remained  invariant,  the  objectives  needed  to  achieve  this  goal 
have  changed,  as  has  the  original  strategy,  because  of  the 
opportunities  presented  by  recent  events.  The  major  objectives  at 
the  completion  of  this  contract,  31  July  1987,  ares 

»• 

.  Develope  a  generic  automated  patient  record  structure 

compatible  with  CHCS,  VA  DHCP,  USPHS  systems  and  standards  for 
non-federal  automated  systems. 

.  Utilize  standardized  terminologies  and  data  representations. 

.  Identify  strategies  for  quickly  and  easily  educating  trauma 

care  personnel  in  the  use  of  automated  information  systems  in  the 
care  process. 

.  Develope  a  Trauma  Registry  linked  to  the  care  record 
structure  for  use  as  a  research  database.  (7-^ 

The  first  major  objective,  that  of  modelling  the  transportabl e 
patient  care  record  on  the  Veterans  Administration  DHCP  system, 
remains  firm  but,  because  of  the  progress  of  the  internal  VA  Special 
Interest  User's  Groups  (SIUGs)  has  not  been  as  rapid  as  expected, 
definition  of  the  segments  of  the  trauma  care  record  that  are 
consistent  with  DHCP  has  been  held  back.  Moreover,  the  one 
alternative  configuration  in  the  CHCS  competition  that  is  based  upon 
DHCP  has  had  to  introduce  new  record  structuring  concepts  for  care 
record  segments  that  may  differ  from  the  current  approach  of  DHCP. 
These  changes  have  held  back  a  consensus  on  the  basic  logical 
structure  of  the  record.  An  ASTM  sponsored  national  voluntary 
consensus  activity  on  the  structure  and  content  of  the  primary  care 
record,  supported  by  the  American  Medical  Record  Association  (AMRA) , 


has  been  organized.  One  product  o-f  this  effort,  supported  by  our 
work,  has  been  the  production  of  a  Standard  Description  o-f  the 
Registration  -  Admitting,  Discharge  and  Transfer  Process  as  a  first 
step.  This  standard  describes  the  Demographic  segment  of  the  care 
record.  The  next  step,  a  standard  description  of  the  entire  primary 
care  record  structure  and  content  is  well  along  but  will  require 
inputs  from  the  federal  VA  DHCP,  USPHS  and  DoD  CHCS  public  projects 
as  powerful  models  to  organize  the  consensus  from  the  private 
sector.  While  involvement  of  federal  agencies  in  the  ASTM 
activities  has  accelerated,  this  process  has  a  ways  to  go  before  it 
is  complete.  In  spite  of  this,  our  current  prototype  data 
dictionary  has  already  incorporated  the  available  features  of  DHCP 
and  CHCS  as  well  as  those  coming  from  the  private  sector. 

Another  major  objective  has  been  to  utilize  terminologies  that  are 
widely  supported  by  consenses,  particularly  those  for  describing 
injury.  The  commencement  of  the  10th  Revision  of  the  International 
Cl assi f i cat i on  of  Diseases  by  the  World  Health  Organization 
coincided  with  the  establ i shment  of  an  ASTM  voluntary  consensus 
activity  to  define  generic  wel 1 -structured  biomedical 
nomenclatures.  These  two  complementary  activities  provided  the 
opportunity  to  define  these  lexicons  to  be  mutually  consistent  so 
that  they  will  meet  the  need  for  a  common  terminology  of  injury. 
While  these  efforts  are  still  ongoing,  we  have  had  a  major  role  in 
both  of  them  and  have  incorporated  the  emerging  terminologies  into 
our  prototype  architecture.  These  ASTM  Standards  efforts  are  now 
also  providing  input  into  the  CDC  national  injury  program.  As  a 
result,  our  efforts  regarding  terminologies  have  already  contributed 
to  the  award  from  CDC  of  a  Center  Grant  for  Injury  Prevention  to 
this  institution. 

A  third  major  objective  has  been  to  identify  the  approaches  to 
educating  the  potential  users  about  the  capabilities  of  the  system 
and  the  procedures  for  using  it.  We  have  used  the  iterative  design 
process  to  compose  dialogs  for  the  Trauma  Registry  component  of  the 
system  and  to  explore  the  layout  and  style  of  interaction  most 
appropriate  in  a  trauma  care  environment.  The  problem  of  getting 
patient  care  data  into  the  system  is  not  a  trivial  task  and,  while 
numerous  approaches  may  be  used,  there  is  little  consensus  about  the 
ways  t*o  gather  descriptive  data  about  the  care  rendered  in  a  trauma 
setting.  When  the  record  structuring  and  data  representation 
(terminology)  issues  are  more  completely  resolved,  it  will  become 
clearer  how  to  approach  the  data  capture  process.  Nevertheless,  the 
data  entry  screens  and  dialogs  for  both  the  Registry  and  the  Trauma 
Care  Record  initial  segments  have  been  developed  to  be  as  convenient 
as  possible  for  learning  about  the  system. 

The  fourth  major  objective  was  to  structure  and  define  a  Trauma 
Registry  research  database  that  would  be  strongly  compatible  with 
the  automated  Trauma  Care  Recur  d  so  that  so  that  data  could  be 


easily  and  accurately  abstracted  from  the  care  record  and  posted 
into  the  Registry.  The  structure  of  this  registry  is  open-ended  and 
can  receive  new  data  -from  the  care  record,  as  the  need  for  it  is 
identified.  The  emphasis  in  the  Registry  has  been  directed  at 
ensuring  accuracy  and  completeness  of  the  collected  data  rather  than 
merely  increasing  the  number  of  elements  for  which  data  is 
collected;  the  number  of  elements  can  be  extended  when  the  ability 
to  machi ne-abstr act  the  care  record  becomes  available  with  the 
regular  use  of  the  automated  care  record. 


Specific  Achievements 


Record  Structure 


In  order  to  have  a  transportable  record  structure  that  can  be 
received  by  DoD  fixed  definitive  care  facilties,  a  common 
generalized  care  record  structure  must  be  agreed  upon.  The  VA  DHCP 
"Patient  File"  record  structure  is  based  on,  and  is  consistent  with, 
work  AMRA  began  in  the  mid  70s  when  DHCP  began.  DHCP  presently 
consists  primarily  of  Regi strat i on-Admi tt i ng ,  Discharge  and 
Transf er (R-ADT)  information,  although  a  number  of  VA  facilities  have 
added  local  extensions  to  contain  clinical  data.  The  PHS/Indian 
Health  Service  (IHS)  has  adapted  the  VA  DHCP  model  and  added  a 
considerable  number  of  data  elements  relating  to  ambulatory  care 
encounters.  The  DHCP  alternative  for  CHCS  has  adopted  a  number  of 
conventions  from  these  efforts  but  no  universal  consensus  has  yet 
been  agreed  upon.  That  general  consensus  will  be  arrived  at  through 
the  ASTM  process  which  will  involve  all  of  the  clinical  specialty 
societies  as  well  as  federal  agencies. 

Because  it  was  recognized  that  this  route  was  the  only  one  likely 
to  be  effective  in  establishing  common  record  structuring 
conventions  that  were  likely  to  be  both  adhered  to  by  all  providers 
and  capable  of  producing  the  conceptual  framework  for  a 
transportabi 1 i ty  format  that  would  draw  on  the  existing  federal 
models,  one  of  our  i nvest i qator s  (AWF)  helped  establish  the  E31.12 
Subcommittee  on  Medical  Informatics  responsible  for  this  area  and  is 


) 


the  current  Secretary  .  The  care-record  transportab i 1 i ty  convention 
itself  will  be  the  product  o-f  E-31.11  Subcommitte  on  Data  Exchange, 
which  we  also  helped  -form,  but  which  will  draw  on  the  work  o-f 
E-31.12.  The  Subcommittee  on  Data  Exchange  has  recently  produced  a 
Standard  Spec  i -f  i  cati  on  -for  the  Exchange  o-f  Laboratory  Requests  and 
Results  Between  Computing  Systems  in  which  we  were  heavily 
involved.  Work  in  this  subcommittee  has  just  begun  on  two  new 
projects:  a  speci -f  i  cati  on  -for  the  exchange  of  medication  data  and  a 
draft  of  the  approach  to  specifying  the  way  to  exchange  the  patient 
care  record,  which  this  facility  is  initiating. 

It  is  important  to  recognize  that  the  two  activities  of  record 
structure  definition  and  record  tr ansport abi 1 i ty  conventions  are 
inextricably  linked.  By  contributing  the  experience  of  this  project 
to  the  standards  del i berat i ons  we  have  been  able  to  reflect  the 
current  consensus  in  our  protoype  care  record  structure.  The 
details  of  this  structure  is  contained  in  the  current  version  of 
TPFUIS  Design  Manual  (Attachment  I).  The  way  that  we  have  related 
the  information  in  this  project  to  the  anticipated  needs  of  the  FMF 
Field  Information  System  was  to  create  a  parallel  prototype  system 
for  the  FMF  in  which  the  record  structure  data  elements  identified 
in  the  FMF  Casualty  Care  workshops  (1,2)  and  the  CHCS  specification 
were  placed  to  avoid  conflict  with  VA  DHCP  elements  but  in  a  way 
that  was  consistent  with  the  emerging  consensus  model  logical 
structure  being  used  in  the  ASTM  process.  The  current  draft  is 
enclosed  as  Attachment  IV.  This  process  will  ensure  commonality 
between  civilian  automated  systems  and  military  field  medical 
records  through  the  medium  of  the  transportabi 1 i ty  convention,  when 
compl eted . 

As  a  means  of  analyzing  the  existing  paper  record,  validating  the 
emerging  logical  data  model  against  this  analysis  and  coordinating 
the  identified  elements  with  the  emerging  consensus  we  created  a 
database  (3)  to  reflect  the  main  dimensions  by  which  data  elements 
are  viewed  and  to  record  data  about  the  data  element  attributes 
which  can  then  be  manipulated  in  parallel  with  the  emerging 
consensus  logical  record  structure.  This  database  allowed  us  to  be 
able  to  identify  the  way  our  current  local  paper  record  system 
reflects  or  conflicts  with  the  emerging  consensus.  A  similar  paper 
analysis  of  the  military  paper  record  system (4)  has  not  yet  been 
incorporated  into  the  data  base,  but  could  be  when  a  common  DoD 
ground  is  identified  for  relating  that  analysis  to  the  CHCS 
specification.  Just  one  of  the  many  possible  perspectives  of  the 
current  data  element  database  is  presented  in  Attachment  VI  while 
the  reference  logical  model  is  shown  in  Attachment  VII.  The  Data 
Dictionary  for  this  database  is  shown  in  Attachment  V. 

This  database  approach  is  far  superior  to  the  F'SA/PSL 
representat i on  used  to  specify  the  CHCS  because  it  has  the  ability 
to  define  the  logical  structure  of  the  record.  It  also  possesses 
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the  ability  to  be  linked  to  system  specification  databases  that 
define  requirements  and  functions  which,  it  should  be  noted,  should 
be  able  to  specify  the  logical  structure  of  the  databases  as  part  of 
the  system  specification.  Though  the  potential  for  software  tools 
to  aid  in  the  full  system  definition  process  is  quite  a  ways  from 
being  met,  the  present  approach  has  been  a  major  aid  in  our  input 
into  the  ASTM  patient  care  record  structuring  effort.  The  three 
year  contract  period  has  s.mply  been  insufficient  to  follow  the 
consensus  procedure  to  its  conclusion,  but  it  has  allowed  this 
project  to  establish  the  framework  and  the  intial  conventions  for 
defining  the  information  needs  of  trauma  care  with  regard  to  the 
global  framework  that  will  be  needed  for  the  transportabl e  record. 

Attention  should  also  be  called  to  the  efforts  now  underway  to 
define  the  patient  record  information  required  for  occupational 
health  survei 1 1 ance.  The  ASTM  E-34  Committee  on  Occupational  Health 
is  col  1 aborati ng  with  E31.12's  efforts  in  this  direction. 
Nevertheless,  the  various  national  agencies  having  an  interest  in 
the  health  effects  of  hazardous  substances  have  not  yet  been  brought 
together  in  a  concerted  way.  This  effort  is  important  for  a  medical 
record  far  military  operational  medicine  information  systems  because 
most  of  the  needed  data  for  occupational  health  are  recorded  as  part 
of  the  routine  "sick  call”  encounters.  This  same  data  also  provides 
the  information  needed  for  other  clinical  per spect i ves ,  such  as  the 
followup  of  injuries.  Such  data  must  be  dealt  with  consistently  and 
within  the  general  structure  of  the  care  record  but  patient  data 
must  be  presented  uniquely  to  each  practitioner  having  a  specialist 
per spect i ve. 

Likewise,  The  combat  casualty  care  aspects  of  the  record  should 
draw  on  the  convergence  of  the  efforts  of  ASTM ' s  F-30  Emergency 
Medical  Services  Committee,  the  CDC  national  Injury  Control  Program 
(which  also  includes  the  CPSC  and  DOT/NHTSA)  in  defining: 
pre-hospital  information  reqtii rements ,  emergency  medical  treatment 
data  and  emergency  medical  services  planning  and  managerial 
databases.  The  col  1 aborati ve  aspects  of  this  joint  effort  has  just 
begun . 

Our  current  prototype  reflects  a  number  of  the  capabilties  that 
will  eventually  be  addessed  by  these  two  perspectives  but  our 
strategy  has  been  to  implement  only  those  data  elements  and  segments 
of  the  record  that  reflect  a  clear  emerging  consensus. 
Nevertheless,  the  DHCP  structure  is  robust  enough  to  accommodate  all 
of  the  logical  structures  which  are  likely  to  be  proposed. 


T  er mi nol ogi es 


The  issue  of  terminologies  for  a  transport abl e  care  record  system 
revolves  around  the  identification  of  the  mode  of  representing  data 
for  each  data  element  in  the  logical  data  structure.  Some  data 
elements  may  require  a  sublexicon  of  terms  that  have  meaning  only 
within  the  context  of  that  element's  location  in  the  record.  Other 
data  elements  may  have  more  general  use  and  thus  appear  in  several 
places  in  the  record,  including  appearing  as  free  text.  Some 
current  automated  care  record  systems  utilize  a  master  dictionary  of 
terms  which  identifies  the  context  of  the  term  and  directs  where  it 
is  to  be  stored  within  the  record.  It  is  not  clear  that  this 
approach  will  work  in  a  trauma  care  setting  where  much  of  the  data 
is  numeric,  date-time  valued  or  from  limited  lexicons.  Narrative 
text  presents  a  major  data  capture  problem  which  it  is  known  would 
be  very  difficult  to  solve  either  in  combat  casualty  care  or  in 
civil iain  mass  casualty  situations.  Nevertheless,  we  have  focussed 
on  a  limited  number  of  sublexicons,  the  two  most  important  of  which 
are:  nature-of-in jury  and  mode-of -i n jury .  Because  the  10th  Revision 
of  the  Internati onal  Cl assi f i cat i on  of  Diseases  (ICD)  and  the  ASTM 
E31.12  Medical  Informatics  activities  on  Biomedical  Nomenclature 
commenced  concurrently ,  we  elected  to  participate  in  both  of  these 
efforts  in  order  to  be  able  to  affect  the  development  of  a  common 
consensus  on  a  terminology  of  injury. 

With  regard  to  nature-of-i n jury ,  the  proposed  10th  Revision  of  ICD 
is  organized  first  by  anatomic  location  and  then  by  type  of  injury, 
though  not  as  specifically  stated  as  the  Abbreviated  Injury  Scale 
(AIS-85)  terminology.  Moreover,  because  the  wording  of  the  ICD-10 
sections  for  nature-of -i n jury  is  less  specific  than  that  of  AIS-B5, 
it  leads  to  several  ambiguities  affecting  injury  scaling.  It  is, 
however,  much  improved  over  the  ICD-9-CM  terminology.  Furthermore, 
John  Hopkins  University  <JHU> ,  in  collaboration  with  the  American 
Association  for  Automotive  Medicine  (AAAM)  proprietors  of  AIS-85, 
produced  a  mapping  of  the  AIS-85  scale  values  into  the  ICD-9-CM 
lexicon,  which  we  obtained,  courtesy  of  Dr.  Ellen  MacKenzie,  Johns 
Hopkins.  We  are  currently  col 1 aborati ng  with  AAAM  and  JHU  as  part  of 
the  ASTM  process  in  order  to  produce  a  unified  dictionary  of  terms 
each  -having  a  code  for  ICD-9-CM,  AIS-85,  ICD-10  and  SNOMED.  This 
unification  will  enable  crosswalks  among  the  existing  terminologies 
to  be  related  to  a  single  preferred  term  which  will  be  expressed 
using  the  generic  rules  of  terminology  to  be  produced  by  ASTM 
E31.12.  The  dictionary  will  also  contain  other  attributes  associated 
with  these  terms  and  it  will  thus  become  the  central  common 
terminology  for  describing  nature  of  injury. 

One  of  our  contributions  has  been  to  formulate  a  structured  way  to 
state  the  three  major  attributes  of  the  nature-of -i n jury  term: 
general  body  location,  detailed  location  and  type  of  injury  in  a 
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-formal  way  so  that  terms  can  be  explicitly  understood  and  indexed  in 
a  conceptually  natural  way  useful  to  practi  tioners.  The  object  of 
this  way  to  express  the  term  was  to  make  it  easy  and  accurate  to 
capture  injury  data  for  the  care  record  once  at  the  source.  Though 
much  remains  to  be  done  in  developing  the  consensus,  we  have 
incorporated  this  representat i on  into  the  lexicons  for  our  prototype 
and  into  our  experi mentati on  regarding  the  best  way  to  access, 
display  and  use  these  data.  These  experimental  efforts  are  also 
being  used  to  foster  the  consensus  process.  One  benefit  of  this 
approach  is  that,  given  an  accurate  and  complete  list  of  terms  of 
injury,  an  injury  severity  score  <ISS>  and  the  AIS  profile  for  each 
body  region  is  immediately  available.  That  benefit  has  already  been 
useful  in  the  Trauma  Registry  Component  of  our  prototype  but  the 
demonstration  of  the  benefits  of  the  immediate  availablity  of  ISS 
and  AIS  data  to  the  Emergency  Room  practitioner  still  needs  to  be 
def i ned . 

With  regard  to  the  mode-of-i n jury ,  we  undertook  to  propose  a 
completely  new  structuring  of  the  terms  based  upon  the  five 
attributes:  mechanism,  agent,  activity,  intent  and  setting  that  were 
reflected  in  the  "E"  codes  of  ICD-9-CM.  By  wide  agreement  the 
ICD-9-CM  organisation  was  very  confusing  because  it  was  first 
grouped  by  intent,  the  most  unreliable  attribute,  rather  than  by 
mechanism,  the  highest  priority,  most  reliable  and  intuitively 
obvious  attribute.  In  concert  with  the  CDC  Injury  Control  Program 
we  have  proposed  to  WHO  that  ICD-10  use  the  first  proposal  for 
mode-of -i n jury  made  jointly  by  CDC  and  the  Nordic  Medical  Statistics 
Council  (NOMESCO)  which  stated  that  the  lexicon  be  ordered  first  by 
by  mechanism  and  then  by  the  other  attributes  in  the  priority  noted 
above.  If  that  proposal  is  eventually  accepted,  this  represent at i on 
will  markedly  simplify  the  recording  of  mode-of -i n jury  in  the  trauma 
care  record.  This  ability  to  easily  and  quickly  record 
mode-of — i n jury  will  significantly  increase  the  availablity  of 
accurate  and  detailed  mode  of  injury  data  for  epidemiologic 
purposes.  The  use  of  this  convention  has  immediate  relevance  for 
the  capture  of  mode-of -i n jury  data  from  combat  casualties.  The 
availablity  of  mode  and  nature  of  injury  data  in  the  combat  setting 
will  provide  explicit  derived  data  which  can  be  used  in  the  patient 
distribution  activities  of  Medical  Regulating,  such  as  that 
addressed  by  the  Army  TAMMIS  system.  In  fact,  one  of  the  major 
reasons  for  our  effort  was  to  be  able  to  easily  and  reliably  get 
that  information  in  a  combat  setting.  DoD  will  need  to  convoke  a 
military  consensus  group  to  agree  on  the  extensions  needed  to 
characterize  combat  injuries,  but  this  can  not  be  done  until  the 
outcome  of  the  WHO  del i ber at i ons  are  known. 

With  respect  to  other  terminologies,  we  considered  the  terms  used 
for  number  of  other  data  elements,  such  as  type  of  admission, 
disposition  and  procedures.  Procedure  terminology  is  the  most 
important;  both  operative  procedures  and  laboratory  terms  need  a 
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common  lexicons.  We  have  participated  in  the  ASTM  Task  Group  which 
is  developing  a  convention  -for  Laboratory  Test  and  Analyte  names 
that  will  provide  a  common  terminology  Tor  both  ordering  laboratory 
tests  and  reporting  the  results.  Because  -few,  if  any,  current 
laboratory  in-formation  systems  report  test  data  by  posting  directly 
to  the  patient  care  record,  the  main  reporting  route  is  by  printed 
summaries.  When  machine  posting  becomes  available,  a  common 
terminology  will  be  required;  a  tr ansportabl e  record  is  vitally 
dependent  upon  this  commonality  o-f  terms. 

With  regard  to  operative  procedures,  ICD-9  terms  are  widely  used 
Tor  inpatients  but  CPT-4  terms  are  used  for  outpatients  and  these 
two  terminologies  are  phrased  differently;  SNOMED  Procedure  terms 
are  used  in  surgical  pathology  reports.  We  have  identified  a 
hierarchy  of  attributes  for  procedure  terminology  starting  with  body 
location  and  type  of  procedure  as  the  most  important,  but  we  have 
not  yet  developed  a  specific  proposal  to  ASTM  at  this  time  because 
WHO  will  not  include  Procedure  terms  in  the  10th  Revision.  Therefore 
the  urgency  to  restructure  the  operative  procedure  terms  does  not 
yet  have  the  priority  of  obtaining  an  agreement  on  the 
nature-of -i n jur y  and  mode-of-in jury  terminology.  Procedure  terms 
will  be  dealt  with  as  soon  as  these  other  terminologies  are  well  on 
their  way  to  consensus. 


Instruction  in  Use 


One  approach  to  learning  about  use  of  the  trauma  care  record 
system  involves  the  design  of  attractive  interactive  dialogs.  The 
data  that  is  generally  captured  in  clinical  settings  is  more  complex 
than  is  regularly  realized.  The  mental  tasks  that  take  place  are 
more  complicated  than  most  have  recogized.  For  example,  in  order  to 
record  the  structured  terms  for  diagnoses  or  operative  procedures 
explicitly  and  in  a  detailed  fashion,  the  presentation  of  the 
information  needed  to  find  a  specific  term  in  even  limited  lexicons 
needs  to  offer  a  quick  and  easy  means  of  looking  up  these  terms. 
One  major  aid  is  a  well  designed  lexicon,  described  above,  but  these 
terms  must  be  rapidly  and  easily  accessible  in  a  powerful  way. 
Windowing  abilities  abound  in  standalone  micro-computera  and 
workstations  needed  to  record  clinical  observations  at  thee 
bedside.  Using  recent  software  toolkits  utilities  for  the  ANSI 
Xll.l  MUMPS  environment  and  improved  terminology,  we  have 
experimented  with  menu/window  presentation  techniques  that  focus 
attention  on  regions  of  the  lexicon  containing  the  terms  relating  to 
the  selections. 
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In  addition  to  more  interactive  visual  displays  we  have  also 
initiated  the  linking  of  interactive  segments  of  user  dialog  to  help 
prompts  within  the  softare  tools.  In  concert  with  VA  investigators, 
we  have  been  using  a  version  o-f  the  authoring  language  PILOT/MUMPS 
that  is  callable  -from  within  the  system  building  tools  (VA  FileMan). 
PILOT  is  an  authoring  language  -for  managing  dialog  in  instructional 
settings;  the  MUMPS  implementation  of  it  has  an  important  property 
that  gives  it  access  to  the  underlying  MUMPS  environment  where  it 
can  call  upon  embedded  instructional  examples  of  how  to  use  the 
system.  Experiments  in  learning  how  to  use  this  capability  in  a 
trauma  setting  are  embryonic  since  the  system  is  still  being  defined 
to  meet  the  emerging  standards.  These  capabilties  were  implemented 
to  identify  the  feasibility  of  conducting  online  instruction  when 
the  system  approaches  its  initial  testing  period  with  untrained 
users. 


Linked  Trauma  Registry 


The  Trauma  Registry  component  was  an  out  growth  of  our  structuring 
of  the  Garr i ck-Carey  Battle  Casualty  Database,  ONR  Contract 
NOOO 14-83-0568  Mod  2  and  became  the  vehicle  for  looking  at  the  data 
elements  to  be  incorporated  into  the  Trauma  Care  Record.  This 
Registry  Component  categorised  and  focused  on  the  data  that  would 
characterize  the  trauma  patient  population  and  highlight  the  data 
issues  that  must  be  dealt  with  in  the  patient  care  record.  The 
technical  capabilties  of  the  Trauma  Registry  are  described  in  refs  4 
&  5  and  the  Documentation  Manuals  are  found  in  Attachment  II  &  III. 
The  major  achievements  are  first,  that  the  registry  record  structure 
is  organized  to  be  closely  similar  to  the  prototype  patient  record. 
For  many  of  the  data  elements  identical  lexicons  are  used  for  the 
correspondi ng  data  elements.  Because  of  the  use  of  the  VA 
FileManager  and  the  pointing  technique,  the  entries  in  the  lexicon 
files  .can  be  categorized  for  the  trauma  registry  and  can  be  seen  as 
category  names  from  the  registry  but  as  the  detailed  entry  from  the 
care  record.  For  many  of  the  correspondi ng  data  elements  in  the  two 
databases,  the  data  elements  access  the  same  lexicon.  This  feature 
f aci 1 i ti tates  automatic  abstracting  of  cases  from  the  care  record  to 
the  registry. 

Even  though  at  the  time  of  completion  of  this  contract,  the  care 
record  prototype  is  not  being  used  to  capture  patient  data  into  the 
automated  record,  the  initial  ability  to  conduct  automatic 
abstracting  of  that  record  is  in  place.  Obviously,  this  abstracting 
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facility  needs  to  be  extensively  tested  before  it  can  be  considered 
operational  but  the  present  environment  has  demonstrated  its 
benefits  which  are  due  to  decreased  personnel  time  and  to  increased 
accuracy  and  convenience  in  collecting  this  data  via  the  direct 
abstract  from  the  patient  care  record.  Such  an  ability  will  be 
necessary  if  the  incentives  for  trauma  facilities  to  generally 
maintain  an  active  trauma  registry  are  expected  to  be  in  place 
before  the  regular  use  of  a  registry  is  mandated  as  part  of  hospital 
routine  operations. 

From  the  work  done  on  the  Battle  Casualty  Database,  this  trauma 
registry  model  was  intended  to  help  define  how  this  same  data  would 
be  employed  in  analysing  casualty  care  in  the  field,  beyond  the 
current  capabilties  which  are  projected  for  TAMMIS  and  other  data 
systems  supporting  patient  distribution  activities  of  Medical 
Regulating.  The  capabilties  of  the  Trauma  Registry  are  in  addition 
to  the  Patient  Accounting  functions  of  these  systems  because  the 
registry  captures  a  variety  of  clinical  data,  both  treatment  and 
outcome  measures,  which  were  not  originally  intended  capabilities  of 
a  system  like  TAMMIS.  The  registry  also  complements  the  automated 
care  record  by  condensing  and  categorizing  much  of  the  data 
originating  in  the  care  record  and  decoupling  access  to  this  data 
from  the  ongoing  activities  involved  in  patient  care,  a  distinction 
that  has  been  noted  in  the  1 i terature (7) . 

The  Trauma  Patient  Care  Followup  Information  System  (TPFUIS) 
prototype  technical  details  are  contained  in  the  TPFUIS  Design 
Manual ,  Attachment  I.  It  is  important  here  to  note  the  basic 
capabilities  of  that  prototype,  and  any  parallels  with  the  FMF 
Prototype  (see  FMF  Prototype  Design  Manual,  Attachment  V).  One 
important  feature  of  the  TPFUIS  prototype  is  its  compatibility  with 
VA  DHCP  and  the  DHCP-al ternati ve  CHCS  System.  Insofar  as  we  have 
been  able  to  gather  information  about  the  CHCS  alternative,  the 
Registration  ADT  functions  of  that  alternative,  the  FMF  Prototype 
and  TPFUIS  are  consistent  not  only  with  each  other  but  also  with  the 
ASTM  requirements  (8)  for  standard  functions.  The  FMF  and  TPFUIS 
prototypes  extend  the  data  in  the  R-ADT  segments  of  the  DHCP  and 
CHCS-al ternati ve  record  to  include  pre-hospital  and  emergency  room 
data  about  injured  patients.  The  placement  of  these  elements  is 
based  .upon  our  experience  with  the  Trauma  Registry  and  it  does  not 
currently  collide  with  VA  DHCP.  Nevertheless,  this  placement  of  data 
elements  is  provisional  because  the  work  of  ASTM  E-31  has  not  yet 
identified,  via  its  coordination  with  ASTM  F-30,  Emergency  Medical 
Services,  the  consolidated  requirements  for  both  the  pre-hospital 
and  in-hospital  acute  care  that  may  be  jointly  identified  by  the 
participating  specialty  societies.  The  structure  of  this  prototype, 
however,  will  allow  these  add i t i ons/changes  to  be  made  as  soon  as 
consensus  is  reached.  The  record  segments  containing  problem  list, 
clinical  orders,  1 aborator y/di agnost i c  data,  medications,  medical 
history,  physical  exams  and  inpatient  care  have  all  been  identified 
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in  the  ASTM  logical  model  but  our  implementation  of  them  has  awaited 
clearer  understanding  of  any  joint  agreements  between  VA  DHCP, 
PHS/IHS  and  CHCS  regarding  a  common  placement  o-f  these  segments 
before  proceeding.  The  placement  of  operative  data  within  the 
inpatient  segment  likewise  requires  further  definition.  At  the 
latest,  the  VA  Surgical  SIUG,  which  advises  DHCP  on  this  subsegment, 
had  not  produced  a  recommendation. 


Implementation  Inf rastructure 


The  project  software  environment  has  utilized  the  ANS  Xll.l  MUMPS 
1 anguage  and  software  management  environment.  Because  the  project 
is  modelled  on  the  DHCP,  it  currently  uses  V.  17.08C  of  VA  FileMan 
and  V.  5.0  of  KERNEL.  Through  use  of  these  sysstem-bui 1 di ng  tools, 
the  ability  to  link  the  Trauma  Registry  component  and  the  TPFUIS 
component  in  a  consistent  fashion  is  provided.  We  have  also  used  a 
proprietary  software  toolkit  from  Patterson-Gray  Associates  that 
handles  menus  and  other  display  aids.  There  are  a  number  of  vendors 
products  of  this  type  on  the  markeet  that  facilitiate  screen 
displays.  The  techniques  used  here  are,  therfore,  not  unique  but 
have  slightly  different  properties  than  if  other  tools  had  been 
used.  The  environment  used  is  a  common  multi-user  ANS  Xll.l  MUMPS 
implementation,  InterSystems  M11+,  and  we  have  avoided 
implementation-dependent  features,  except  where  clearly 
sequestered.  The  systems  can  therefore  be  ported  to  any  environment 
offering  a  valid  ANS  Xll.l  MUMPS  language  processor;  the  newer 
features  of  the  language,  such  as  parameter  passing,  are  not  used. 
The  Trauma  Registry  component  using  the  tool  kit  utility  generally 
is,  however,  not  strictly  device  independent  because  it  uses 
function-key  escape  sequences.  Nevertheless,  the  software 
understands  the  device  characteri stsi cs  via  tables  which  currently 
contain  attributes  for  only  the  most  common  devices.  Therefore,  if 
further  device  attributes  are  included  in  the  tables,  a  wide  variety 
of  devices  can  potentialy  be  used  with  the  Registry.  These  screen 
display  techniques  are  not  yet  fully  used  in  the  TPFUIS  component 
where  we  still  use  standard  VA  FileMan  scrolling  dialog  techniques 
in  many  places  during  the  requirements  definition  phase. 

The  above  achievements  are  noted  to  underline  the  fact  that  though 
the  patient  care  record  component  is  still  in  a  rough  prototype 
phase  in  order  to  allow  exper i mentati on  with  the  implications  of 
standards  for  the  patient  care  record,  the  Trauma  Registry  component 
is  a  fully  operational  working  tool.  Even  though  daily  data  are 
being  collected  using  this  component  and  research  into  aspects  of 


patient  care  is  being  conducted,  the  Registry,  too,  is  still  in  a 
state  of  software  evolution.  Over  the  past  four  years  the  registry 
ha^  migrated  from  the  original  Apple  11+  ANSI  Xll.l  MUMPS 
environment  to  the  current  PDP  11/73  host  and  it  has  undergone  a 
number  of  restructurings  to  accommodate  new  requirements  for  the 
representati on  of  data  elements  or  for  the  reorganization  of 
database  data  elements,  based  on  active  use.  No  data  was  lost  in 
any  of  these  actions  nor  was  the  schedule  of  data  collection  delayed 
unduel y.  This  was  due  entirely  to  the  power  of  the  ANS  Xll.l 
environment.  Further  exploration  and  documentation  of  the 
information  processing  conventions  needed  to  structure  a 
transportabl e  patient  care  record  will  be  dependent  upon  this 
technical  capabiltity. 

It  is  important  at  this  point  in  the  discussion  of  the 
implementation  setting  to  address  the  approach  to  engineering  and 
documenting  the  software  for  this  project.  The  goal  of  the  project 
was  to  "explore  and  document"  concepts  of  information  representation 
and  structuring,  an  activity  that  is  classed  as  requirements 
definition.  It  is  a  requirement  to  not  only  document  the  tools  used 
but  also  to,  if  possible,  design  modules  that  are  capable  of 
evolving  into  fully  operational  systems.  Therefore,  good  system 
documentation  is  required.  Because  one  of  the  originally  envisioned 
tasks  was,  and  still  is,  to  fully  excercise  the  patient  care  record 
system  in  an  active  trauma  care  faciltity,  the  approach  to  jointly 
documenting  both  the  concepts  and  the  tools  needs  to  recognise  any 
standards  that  describe  good  software  engineering  practice.  In 
recent  years,  several  national  voluntary  consensus  standards  groups 
have  published  such  standards  (9).  It  is  important  to  note  that 
while  each  of  these  published  standards  represents  a  major  step  in 
documenting  the  activities  involved  in  engineering  a  "product",  they 
have  each  not  fully  recognized  the  approaches  that  are  termed  "Rapid 
Prototyping"  and  "Artificial  Intelligence".  These  terms  are  still 
indistinct  in  what  they  mean  to  differrent  groups. 

The  achievements  of  this  report  were  conducted  using  the  "Rapid 
Prototyping"  and  "Iterative  Devel opement "  (10)  approaches.  As  noted 
earlier(ll),  the  requirements  definition  activities  -  the  earliest 
phase  -  can  be  markedly  accelerated  by  using  the  rapid  prototype 
approach.  What  is  done  in  that  approach  appears  outwardly  to  be 
markedly  different  from  the  process  described  in  a  number  of 
software  engineering  standards  but  it  really  is  not.  Basically, 
however,  each  iteration  undergoes  active  change  leading  to 
improvement  of  a  given  feature  through  online  coding  dialog,  test, 
debugging  and  retest,  all  procedures  in  the  traditional  approach.  A 
development  period  which  leads  to  a  stable  system  is  termed  a  new 
"Version",  which  can  then  be  archived  and  controlled  by 
configuration  management  procedures  and  the  changes  documented  both 
as  software  and  requirement  (conceptual)  changes.  While  we,  in  a 
research  environment  do  not  maintain  a  strict  system  of 
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conf  i  qurati  on  management  or  val  i  dat i  on/ ver  i  f  i  cat i  on/correctness 
activities  because  these  are  based  largely  upon  pre-determi ned 
requirements,  we  do  test  and  document  the  system  at  various  nodal 
points.  Attachments  I  &  III  are  examples  of  the  documentation  of 
the  two  components  at  specific  nodes  but  should  not  be  looked  at  as 
■final  or  definitive  because  o-f  the  evolutionary  nature  of  the 
project.  This  documentation  is  an  important  aid  in  being  able  to 
inter-relate  the  two  components  to  each  other  and  to  VA  DHCP  and 
CHCS  both  at  the  conceptual  level  and  the  physical  level  used  to 
port  systems  from  one  environment  to  another.  It  should  be  clearly 
understood  that  such  documentation  is  only  a  "snapshot"  of  the  the 
system  as  of  31  July  1987.  Nevertheless,  the  procedures  utilized  in 
this  project  can  be  related  to  those  recommended  in  these  various 
software  engineering  standards  for  various  points  in  the  lifecycle, 
even  though  such  standards  do  not  yet  explicitly  deal  with  "Rapid 
Protyping"  and  "Iterative  Devel opement "  processes  in  life  cycles. 
Such  documentation  will  be  required  for  eventually  engineering 
operational  field  medical  information  systems. 

Our  experiments  in  developing  responsible,  yet  practical, 
approaches  to  the  documentat i on  of  a  system  used  for  requirements 
definition  has  further  benefitted  the  ANSI  XI  1.1  MUMPS  standards 
process  in  formulating  documentat i on  standards  for  the  MUMPS 
environment  that  are  consistent  with  emerging  software  engineering 
standards  and  practice,  since  one  of  the  investigators  has  chaired 
the  SC  #3  on  Documentation  for  the  ANSI  XI 1.1  body  since  1978.  He 
has  thus  been  able  to  use  the  lessons  of  this  project  to  help 
establish  coordination  of  ANSI  Xll.l  with  ISO,  ANSI  X3,  ASTM  and 
IEEE  with  regard  to  documentation  and  project  management  standards. 
This  coordination  has  been  possible  because  in  the  last  few  years 
all  of  these  standards  efforts  have  identified  the  need  to 
coordinate  their  activities  to  produce  compl ementary  standards  that 
are  accepted  and  used  to  yield  quality  software.  The  influence,  of 
course,  has  been  mutual. 


Impacts  of  the  System 


The  system  has  had  a  number  of  impacts  on  the  trauma  care 
environment  at  Harborview  and  also  upon  other  associated 
organi zat i ons  and  projects.  The  details  of  the  technical  impacts  on 
standards  groups  were  dealt  with  in  the  sections  above.  The  details 
of  the  impacts  on  trauma  care  will  be  dealt  with  in  this  section. 

The  impacts  of  better  information  availability  on  the  clinical. 
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research  and  management  aspects  o-f  trauma  care  are  not  always  easy 
to  quantity.  To  deal  first  with  the  clinical  aspects,  i.e. 
providing  information  to  those  that  care  for  patients,  the 
availability  of  synoptic  information  has  provided  a  heightened 
awareness  of  what  kinds  of  patients  the  facility  is  actually 
receiving  while  specific  care  data  has  focussed  on  particular 
patient  problem  areas.  For  example,  the  availability  of  the  Annual 
Summary  to  the  various  Nursing  Supervisors  in  the  trauma  units  has 
led  to  their  using  it  for  a  variety  of  planning  and  management 
purposes.  Moreover,  data  on  specific  patient's  profiles  have  been 
used  by  these  same  supervisors  for  case  reviews.  In  view  of  the 
time  lag  due  to  capturing  the  data  from  paper  documents,  this 
benefit  has  been  less  than  might  be,  if  machi ne-ai ded  abstracting 
were  available. 

The  research  aspects  involve  clinical  management  issues,  such  as 
blood  usage,  which  has  been  a  major  interest  of  at  least  one  member 
of  the  Sugery  faculty.  The  ability  to  get,  store  and  extract  data 
about  blood  usage  has  enabled  numerous  discussions  about  policies 
for  blood  resource  management  as  well  as  the  production  of  research 
studies  for  the  literature.  A  variety  of  research  projects,  such  as 
that  on  head  injury,  have  used  data  and  data  gathering  procedures 
developed  by  the  Trauma  Registry  in  order  to  design  rigorous  valid 
detailed  clinical  research  studies.  The  CDC-funded  Injury 
Prevention  Cnter  has  made  extensive  use  of  the  Registry  data  in 
designing  interventions  for  pediatric  injury  and  for  organizing 
arguments  made  to  the  state  legislature  in  support  of  legislation  to 
require  helmets  for  motorcycle  riders  in  this  state.  The  extent  of 
the  studies  supported  range,  forr  example,  from  a  focussed  look  at 
knee  injuries  for  the  Radiology  Dept  to  a  broad  look  at  bicycle  head 
injury.  The  value  of  the  Registry  to  all  of  the  institution's  users 
is  based  upon  the  value  to  them  of  a  database  of  complete,  accurate 
data  for  the  data  that  is  collected.  That  value  would  be  increased 
if  all  of  the  data  collected  were  available  within  24-72  hours. 
This  can  be  achieved  with  the  current  constellation  of  data  elements 
when  the  data  are  collected  for  the  patient  care  record  so  that 
abstracting  can  be  machi ne-ai ded ,  whereas  this  task  becomes  very 
difficult  when  the  source  is  the  manual  paper  record.  When  the 
constellation  of  data  elements  is  expanded  to  include  complex 
selection  criteria  for  clinical  events  to  be  abstracted, 
machine-aided  abstracting  will  provide  the  only  economically 
feasible  alternative  for  attaining  full  synoptic  and  selected  care 
data  quickly.  Thus,  decisions  relating  to  clinical  management 
policy  that  depend  upon  timely  data  will  be  major  beneficiaries  of 
the  automated  collection  of  trauma  patient  care  data. 

The  health  care  facility  management  isssues  that  have  benefitted 
from  the  availablitiy  of  Trauma  Registry  data  include  focussed 
studies  of  costs  on  selected  classes  of  patients  which  draw  on  the 
clinical  data  obtained  by  the  Trauma  Registry  that  are  not  available 
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in  the  current  management  data.  Our  efforts  to  input  case  mix  data 
on  Registry  patients  that  is  extracted  from  the  State  management 
database  will  continue.  Several  studies  are  underway  to  compare  the 
cost  and  resource  consumption  profiles  that  are  derived  from  the 
case  data  collected  by  the  Trauma  registry  with  that  obtained  from 
the  case  mix  database.  The  results  from  these  studies  will  reveal 
whether  there  are  inaccuracies  in  the  estimated  resource  consumption 
for  trauma  patients  and  may  suggets  changes  in  the  reimbursment 
policies.  It  is  important  here  to  recognize  the  overlap  between 
data  characterized  as  "clinical"  and  data  usually  thought  of  as 
"management"  in  order  to  perceive  the  ways  that  these  two 
perspectives  may  be  synergistic  in  developing  the  policies  used  in 
operating  a  trauma  care  facility. 

The  list  of  recorded  studies  requesting  data  from  the  Trauma 
registry  and  the  bibliography  of  reports  and  publications  emanating 
from  this  project  are  contained  in  Table  1  and  Appendix  I 
respcti vel y . 


FUTURE  CHALLENGES 


This  project  is  not  complete.  The  goals  remain.  Because  of  the 
new  realities  of  important  new  standards  activities  that  could 
produce  wide  consensus  on  the  establishment  of  the  concepts  that 
underpin  transpor tabi 1 i ty ,  the  objectives  concerning  the  structuring 
of  a  transportabl e ,  generalized  trauma  patient  care  record  had  to  be 
modified.  It  was  more  important  to  establish  the  organizational  and 
procedural  infrastructure  that  could  achieve  those  objectives  than 
to  rapidly  push  into  a  working  prototype  that  was  not  based  upon 
central  concepts.  Now  that  standards  inf rastructure  is  in  place. 
The  challenge  for  the  future  is  to  push  the  standards  machinery  to 
reach  fundamental  consenses  on  core  issues  as  rapidly  as  is 
possible.  The  core  concepts  of  a  common  care  record  logical 
structure  definition,  a  transport  format  convention  and  commonly 
accepted  and  used  terminologies  will  be  the  main  thrusts  in  that 
effort.  The  approach  that  this  project  should  take,  based  upon  the 
achievements  to  date,  will  now  be  discussed. 
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Complete  Implementation  of  a  Record  Compatible  witth  DHCP  and  CHSt 


The  major  public  models  for  the  logical  structure  of  the  primary 
care  record  are  the  VA  DHCP  and  the  DoD  CHCS;  the  PHS  Indian  Health 
Service  is  already  using  the  DHCP  model  and  other  activities  within 
PHS  are  also  adopting,  or  considering  adopting,  the  DHCP  model.  The 
DoD  CHCS's  DHCP-al ternati ve  is  being  closely  evaluated  with  three 
others  in  the  competition  for  automation  of  fixed  definitive  care 
facilties;  at  the  very  minimum,  however,  that  alternative  will 
operate  in  a  military  MTF  for  three  years  and  will  thus  be  an 
important  public  model  for  the  concepts  essential  to  automted 
primary  care  record  systems.  As  such  a  model,  it  will  undoubtedly 
have  major  influence  on  the  VA ' s  DHCP  in  any  case.  DHCP  and  its 
CHCS-al ternati ve  have  been  our  models  for  a  powerful,  robust  field 
medical  system  concept  capable  of  accommodating  trauma  care.  The 
future  challenge  will  be  to  flesh  out  those  data  areas  that  have 
been  dealt  with  neither  by  VA  DHCP  nor  by  CHCS.  Additional  data 
areas  serving  Occupational  Health  are  rel event  to  a  comprehensive 
automated  field  medical  care  record  and  they  are  complementary  to 
trauma  care  because  they  also  encompass  the  disease,  non— battle 
injury  (DNBI)  information  requirements  of  a  field  system  in  addition 
to  accommodati ng  the  routine  care  of  non-wartime  field  operations  of 
deployed  forces.  These  areas  are  covered  by  other  standards  groups 
operating  in  concert  with  the  ASTM  E-31  information  system 
activities.  The  challenge  at  this  contract  termination  is  to 
develope  a  consistent  conceptual  framework  that  enables  all  of  these 
health  care  issues  to  be  evenly  addressed. 


Develope  and  Test  a  Transport  Format  Consistent  with  National 

Standards! 


When  the  RATIONALE  for  the  logical  structure  of  the  primary  care 
record  becomes  clear,  a  notation  for  describing  that  structure  on  a 
transfer  medium  can  be  devised.  Such  an  effort  has  just  begun, 
based  upon  some  of  the  perspectives  of  this  project.  The  need  for  a 
common  transfer  format  has  been  identified  some  years  ago  by  the 
American  Medical  Record  Association.  The  transfer  convention's 
utility  to  a  care  facility  is  based  upon  the  value  of  receiving  a 
clear,  systematic  record  of  prior  care,  in  an  automated  form,  from 
the  transferring  facility  when  the  patient  arrives  at  a  receiving 
facility.  This  is  an  identified  generic  requirement  for  all  health 
care.  Its  value  to  trauma  care  and  military  echeloned  care  lies  in 
the  ability  of  a  casualty  care  MTF  to  get  data  regarding  prior  care 
in  a  timely  fashion  for  severely  injured  patients.  Until  very 
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recently  this  requirement  has  had  a  remote  chance  of  being  met.  The 
consensus  on  a  record  structuring  convent\tion  will  make  possible 
the  use  of  a  formatting  convention  that  will  reflect  a  universal 
logical  structure  that  all  facilities  can  either  produce  or  read  so 
that  data  on  the  transfer  medium  can  be  inserted  into  their 
automated  care  record  system.  Since  few  automated  patient  care 
record  systems  have  existed  until  recently  and  those  that  did  exist 
did  not  accommodate  longitudinal  patient  care  data,  the  DHCP  model 
has  provided  the  large  public  model  that  illustrates  the  potential 
of  the  transportabl e  care  record,  in  spite  of  the  fact  that  the  VA 
patients  generally  are  not  as  highly  mobile  as  injured  patients  or 
that  the  VA  has  not  yet  extensively  tested  the  record  transfer 
capability  at  this  time.  The  influence  on  the  health  care  industry 
of  the  ermrging  consensus  regarding  the  primary  care  record  logical 
structure,  of  the  VA  DHCP  and  of  the  CHCS  competition  will  make  it 
possible  to  test  this  capabiltiy  on  highly  mobile  patients.  The  VA 
will  want  to  do  this  to  be  able  to  discharge  its  responsibility  to 
DoD  under  the  CMCHS  agreements  in  additon  to  improving  its  ability 
to  manage  the  care  of  its  mandated  constituents.  Therefore,  the 
challenge  posed  at  the  time  of  this  contract  completion  is 
heightened  beyond  just  the  patient  care  transportabi 1 i ty 
requirements  of  trauma  care  to  include  its  potential  benefit  to 
civilian  health  care  generally. 

The  critical  capabilties  needed  to  produce  software  features  for 
transportabi 1 i ty  are  already  built  into  the  CHCS  DHCP-alternative 
software  being  delivered  as  part  of  the  current  competition.  The 
challenge  to  this  project  is  to  obtain  permission  to  use  these 
features  and  to  provide  a  test  bed  for  the  concepts  used  in  the 
transport  format  convention  being  produced  within  ASTM  standards 
activity.  If  that  is  done,  the  transport abi 1 i ty  concepts  can  be 
demonstrated  and  the  validity  of  the  convention  shown.  This  will 
allow  these  common  conventions  to  be  introduced  into  the  field 
medical  information  software  at  the  earliest  time,  thereby  making 
possible  force  medical  readiness  conditions  not  heretofore 
attainable.  Though  the  benefits  to  civilian  care  are  equally  great, 
but  not  so  urgent,  the  two  requi remenbts  are  synergistic  and  will 
have  major  effects  on  the  organization  of  patient  care  when  such 
data  can  regularly  be  transferred  from  facility  to  facility.  The 
full  benefits  to  patient  care  of  the  telecomunications  medium  can 
then  be  realized.  So  that  is  the  true  challenge  and  the  information 
transportabi 1 i ty  critical  step  which  the  other  standards  efforts 
underpin. 


^  Link  the  Care  Record  with  the  DIN/PACS  Structures 

> 
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Another  major  component  in  the  exchange  of  patient  data  is  the 
exchange  of  image  type  data  -formats.  In  recent  years,  the  the  use 
o-f  imaging  technology  to  gain  non-invasive  data  on  patients  has  used 
digital  forms  of  image  management  instead  of  traditional  film 
technology.  The  quality  of  digital  data  is  now  such  that  digital 
images  can  convey  as  much  information  as  can  be  contained  in  film 
images  but  digital  methods  have  far  more  power  to  extract  really 
meaningful  clinical  information  than  does  the  film  medium.  While 
both  the  digital  imaging  technology  and  the  science  of  identifying 
biological  signals  produced  by  patients  that  can  be  manipulated  with 
this  technology  are  in  the  growth  phase,  the  present  state  of 
techology  forces  the  patient  record  issues  to  be  addressed  at  this 
time  and  related  to  the  portable  care  record  issues.  Images  can  now 
be  transmitted,  stored  and  archived  by  a  wide  variety  of 
telecommunications  technology.  In  fact  during  the  1970's  the  U.  S. 
Navy  demonstrated  the  communication  and  interpretation  of  images 
from  deployed  ships  half  around  the  world  and  it  commissioned 
prototype  shipboard  communications  stations  to  be  designed  and  built 
to  tranfer  both  images  and  patient  record  data  in  a  variety  of  ways 
from  ship-to-ship  and  shi p-to-shore  in  a  fashion  compatible  with 
other  demonstrations  of  the  use  of  this  same  technology  in  medically 
underserved  areas.  The  challenge  identified  at  the  completion  of 
this  contract  is  to  develope  those  conventions  for  linking  the 
record  and  the  images  together  as  an  integral  structure  which  can  be 
transferred  together.  This  capability  is  particularly  relevent  to 
trauma  care  where  the  clinical  record  must  be  available  for  optimal 
i nterpretat i on  of  recorded  images.  The  applicability  of  this 
requirement  to  casualty  care  is  obvious. 

The  DIN/PACS  project  at  this  institution  has  only  recently 
commenced  but  its  significance  with  respect  to  this  project  was 
never  underestimated  and  was  expostulated  during  the  formulation  of 
the  DIN/PACS  proposals  from  this  institution.  The  challenge  will  be 
to  coordinate  the  thrusts  of  the  two  projects  in  order  to  produce 
and  test  the  conventions  that  will  allow  consistent  integration  of 
image  and  primary  care  record  data.  The  tranportabl i ty  of  the 
combined  data  package  must  then  be  adequately  demonstrated  in  an 
active  trauma  care  setting. 


Extend  and  Test  Automatic  Abstracting* 


It  has  been  sel f-evident < 12)  for  some  time  that  most  of  the 
epidemiologic  and  management  data  about  health  care  and  health  care 
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services  comes  largely  from  the  primary  care  record,  augmented  by 
other  records  that  contain  data  about  resources  not  connected  to  an 
individual  patient.  It  is,  therefore,  clear  that  the  cost  of 
extracting  this  information  is  far  less  from  a  systematic,  automated 
primary  care  record  than  from  a  hand  written  manual  paper  record. 
With  the  arrival  of  a  common  convention  for  understanding  the 
systematics  of  primary  care  record  structure,  the  ability  to 
abstract  and  categorize  data  into  aggregates  needed  for  management 
(such  as  cost  identification  and  cost  management)  and  for  research 
(such  as  epidemiology  and  clinical  research)  is  also  enabled. 

The  challenge  here  is  to  understand  how  to  focus  this  ability  and 
give  management  personnel  the  data  they  need  to  manage  resources  and 
to  give  clinicians  the  case  data  needed  to  understand  the  processes 
of  patient  care.  It  was  noted  above  that  tools  and  techniques  have 
been  put  in  place  for  this  activity.  The  DHCP  environment  has  great 
potential  for  their  use,  but  understanding  the  needs  for  management 
data  and  identify  their  origins  in  the  primary  care  record  will 
largely  depend  upon  experience  in  using  these  tools,  since  the  the 
management  and  patient  care  professionals  have  had  little  experience 
in  direct  dialog  on  this  subject  in  the  past.  We  have,  in  the  past, 
advocated  the  use  of  such  a  dialog  and  now  put  software  tools  in 
place,  such  as  the  Trauma  Registry  and  the  prototype  primary  care 
record,  but  the  challenge  will  be  to  fully  exercise  thi3  environment 
in  order  to  identify  the  steps  that  are  the  most  productive  as  well 
as  the  data  that  are  the  most  enlightening.  That  is  a  major 
chal lenge. 


Interface  with  Standards  for  Pre-Hospital  Care 


Only  in  the  last  few  years  have  patient  care  information 
professionals  and  the  Emergency  Medical  Care  Specialists  and 
Traumatologists  begun  to  discuss  the  information  requirements  of  the 
entire  Emergency  Medical  Services  Support  System.  It  is  obvious  that 
the  pre— hospital  care  system  should  smoothly  interface  with  the 
in-hospital  trauma  care  system  and  yet  the  information  management 
subsystems  activities  in  both  these  environments  have  pursued 
largely  i ndependendent  courses.  In  the  military,  the  system  is  far 
more  integrated  when  in  wartime.  However,  the  military  has  been 
forced  to  use  the  local  civilian  EMS  for  routine  peacetime  emergency 
care  of  its  members  because  the  civilian  sector  has  largely  not 
structured  itself  to  use  concepts  learned  from  the  military 
operation  of  the  Continuum  of  Care.  The  challenge  to  the 
developement  of  information  management  of  pre-hospital  care  data  in 
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this  project  will  be  to  work 
ASTM  Committees  dealing  with 
to  implement  and  test  as 
conventions  as  is  feasible 
information  integration.  We 
bat  the  real  test  for  us,  as 
sufficiently  powerful  prototype 


with  the  task 
the  different 
many  of  the 
in  order  to 
have  helped 


groups  from  the  different 
phases  of  the  problem  and 
proposed  data  management 
help  prove  their  value  to 
establish  those  linkages 
for  others,  will  be  to  provide 
software  tools  for  testing  the 


proposed  common  conventions  so  that  their  benefits  to  both  the 
pre-hospital  and  in-hospital  pract i ti oners  will  be  self-evident  and 
they  will  use  them.  With  the  current  pace  of  standards  development 
as  rapid  as  it  is,  that  testing  time  lies  in  the  very  near  future. 
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